Method, apparatus, and computer program product for efficient server response generation using intermediate state caching

ABSTRACT

Disclosed is a system for improving server efficiency by caching intermediate states encountered in generating responses to requests. The results of a mapping from an external name for a resource to an internal name for the resource may be cached as may the response header lines, or the body of the response message. In another disclosed aspect, candidates for intermediate state caching are selected from plain and small files. When the resource involves the product of an executable, another aspect involves delaying parsing request headers until necessary and then only parsing the headers required for generating the response.

FIELD

[0001] Features of the invention relate generally to server performanceimprovements and, more particularly, to performance improvements basedon elimination of repeated processing.

BACKGROUND

[0002] A server receiving numerous requests for resources within a briefperiod of time must be highly efficient in generating responses if theserver is going to fulfill the requests within an acceptable period oftime. One illustrative context where this problem arises is inconnection with Enhanced Television (“ETV”). In the ETV context,typically a video production is distributed to numerous clientapplications. The video production has associated with it one or moreenhancing resources that may be selected by a viewer of the videoproduction. Conventionally, the enhancing resources are made availableto the viewer by including an identifier of the resource in the videoproduction. The viewer's client platform, e.g., a set-top box orcomputer, extracts the resource identifier and provides an indication tothe viewer that enhancing resources are available. If the viewer selectsthe resource, a request is sent with the client application resident inthe viewer's client platform. Frequently in the ETV context, numerousclient applications each send requests contemporaneously. This aspect istypically present when, for instance, the video production is broadcastand each viewer becomes aware of the availability of the enhancingresource from the broadcast video production virtually simultaneously.It would thus be desirable for operators of servers receiving numeroussimultaneous requests for server efficiency to be improved.

[0003] Unfortunately, conventional servers are not highly efficient. Forinstance, when a conventional HTTP server, receives a request for auniform resource identifier (‘URI’) it first parses the request, thenparses header lines in the request. Next, the HTTP server applies arewrite mapping process that transforms an external name for theresource (in the URI) to an internal name used for locating the resourceand generating the response. Conventional modules for performing therewrite mapping are powerful and flexible, but obtain this power andflexibility only through computational expense. After the HTTP serverderives an internal name of the resource it must generate the response(by retrieving the associated file and/or running executable code) aswell as generating headers for the response. If a request for the sameresource, were to arrive at the server an instant later, a conventionalserver would repeat the foregoing steps. In a context where there arenumerous simultaneous requests for the same set of resources,conventional server processing is needlessly redundant and inefficient.

[0004] Another type of conventional server is a caching proxy server. Acaching proxy server is a conventional server which stores locally (orat least more locally) to a client certain resources that are requestedfrom hosts on a data network, typically the internet. In this way acaching proxy server reduces response time by reducing or eliminatingtime lags introduced by having to retrieve the resource from a remotehost, that may only be available through a slow or congested networkconnection. However, the caching proxy server does not reduce thatcomponent of total response time that is attributable to processing atthe sever; a conventional caching proxy must flow through all of theintermediate states as any other server in generating a response. Forexample, a caching proxy server retains the inefficiencies of aconventional HTTP server in redundantly performing the mapping from anexternal name to an internal name for repeatedly-requested resources.Indeed, where delays in response time are introduced not from networklags, but from the sheer request volume at the server, a caching proxyserver may provide no noticeable benefits to the user whatsoever.

[0005] Accordingly, it would be desirable for there to be a means forreducing redundant processing in serving repeated requests for aresource.

SUMMARY

[0006] In order to provide these and other objectives, one aspect of thepresent invention are methods for efficiently generating responses forrepeated resource requests. An exemplary method includes: receiving afirst request for a first resource; deriving intermediate stateinformation used in generating a first response to the first request andcaching the intermediate state information. Then when a second requestis received, retrieving the intermediate state information; andgenerating a second response to the second request using theintermediate state information. Illustrative examples of what theintermediate state information may comprise include: an internal namecorresponding to the first resource and a type of the first resource;the first resource; or a plurality of response header lines for thefirst resource.

[0007] Another aspect of the present invention are apparatuses, such asprogrammed computing hardware, configured for efficiently generatingresponses for repeated resource requests. An exemplary apparatusincludes: a request receiver configured for receiving a first requestfor a first resource; a request handler configured for derivingintermediate state information used in generating a first response tothe first request; a cache storing the intermediate state information;and a request handler configured for retrieving the intermediate stateinformation and further configured for generating a second response tothe second request using the intermediate state information. Thisapparatus may operate, for instance, with similar types of intermediatestate information as the forgoing methods.

[0008] A still further illustrative method includes: receiving a firstrequest for a first resource, the first request comprising a resourceidentifier and request modifying information; determining whethergenerating a response for the first request requires parsing the requestmodifying information; and, if not, generating the response withoutparsing the request modifying information. An illustrative apparatusincludes: a request receiver configured for receiving a first requestfor a first resource, the first request comprising a resource identifierand request modifying information; a response generator configured forgenerating a response to the first request and further configured fordetermining whether generating the response requires parsing the requestmodifying information; and a request modifying information parserconfigured to parse request modifying information only when the responsegenerator determines generating the response requires parsing therequest modifying information.

[0009] Yet another aspect of the present invention are computer programsproducts comprising a computer-readable medium having computer readableinstructions encoded thereon for efficient server response generationusing intermediate state caching. The computer-readable instructions areable to configure computing machinery to carrying on methods inaccordance with the invention, or to configure an apparatus inaccordance with the invention. So configured, computing machineryprovides structural elements for performing functions in accordance withthe invention.

[0010] In accordance with the forgoing, a summary of an illustrativeembodiment may be provided: an HTTP server is modified to carry out theinvention; when an HTTP Request Message (comprising a URI) arrives, theserver determines if a URI descriptor has already been cached. If not,one is generated. If the request is for a small, plain file, the fileand response headers are cached and read out to generate the response.If the response is for an executable, the headers in the Request Messageare parsed and the executable generates the response. When a secondrequest arrives for the resource, the server can consult and locate thecached URI descriptor and read out the cached response headers and body.As will be appreciated with reference to the detailed description,illustrative embodiments of the invention obtain efficiencies such as,but not limited to: eliminating parsing of headers in requests untilnecessary and then only parsing the required headers; caching the costlymapping between an external and internal name for a resource andeliminating redundant processing in repeated requests; caching responseheaders and body and eliminating redundant processing in repeatedrequests.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] These and other features, aspects, and advantages of the presentinvention will become better understood with regard to the followingdescription, appended claims, and accompanying drawings where:

[0012]FIG. 1 depicts a cache data architecture in accordance with anillustrative embodiment;

[0013]FIG. 2 is a flow diagram of a method for efficient server responsegeneration using intermediate state caching in accordance with anillustrative embodiment; and

[0014]FIG. 3 depicts a computer system capable of being configured toembody aspects of the invention in accordance with an illustrativeembodiment.

DETAILED DESCRIPTION

[0015] Description of Figures

[0016]FIG. 1 depicts a cache data architecture 1000 in accordance withan illustrative embodiment of the invention. The cache data architecture1000 may be used to store information from intermediate states ingenerating a response to a request for a resource. When another similarrequest is received, the response may be more efficiently generated byretrieving the intermediate state information from the cache dataarchitecture 1000 rather than regenerating the intermediate stateinformation. Generation and use of the cache data architecture 1000 willbe discussed in greater detail in connection with FIG. 2 below.

[0017] The illustrative cache data architecture 1000 includes a hashtable 1100 comprising a number of ‘buckets’ (denoted “B” in FIG. 1 forsome positive integer, B, chosen conventionally). Associated with eachbucket are a set of URI Descriptor data structures entered in the hashtable 1100 for storage and retrieval. Illustratively, shown are a firstURI Descriptor data structure 1200, a second URI Descriptor datastructure 1300, and an N^(th) URI Descriptor data structure 1400. Thecomposition of the URI Descriptor data structures is illustrated incallout 1450 from the N^(th) URI Descriptor data structure 1400.

[0018] In this illustrative embodiment, the N^(th) URI Descriptor datastructure 1400 comprises a first variable 1455 indicating whether theresource is cached, a second variable 1460 enumerating the type of fileassociated with the resource, a third variable 1465 comprising aninternal name for the resource associated with the URI, a fourthvariable 1470 comprising a length of the resource associated with theURI, a fifth variable 1475 comprising a length of headers for theresponse, a sixth variable 1480 referencing a cached response body 1500,and a seventh variable 1485 referencing a cached response header 1600.

[0019] One of skill in the art will appreciate that this particular dataarrangement is merely illustrative, that others may be used, that theothers may include or exclude variable(s) without departing from thescope and spirit of the present invention or this illustrativeembodiment, and that data structures accomplishing analogousdata-organizing functions may be used in numerous programmingenvironments, irrespective of whether a given language supports the datatypes illustrated.

[0020] The cached response body 1500 and the cached response header 1600are preferably stored in random access memory. Conventional systems mayswap memory to mass storage, and such systems may also be used. Moregenerally, any storage system proving suitably rapid access should beoperable with features of the invention.

[0021]FIG. 2 depicts a flow diagram of an ‘efficient responsegeneration’ method 2000 in accordance with an illustrative embodiment.To more concisely describe FIG. 2 reference will be made to oneparticular instance of a URI Descriptor data structure, mnemonically“d”, similar to the N^(th) URI Descriptor data structure 1400. In thisillustrative embodiment, steps of this method are performed by a serverprocess, for instance a suitably modified version of the Apache HTTPserver (available from <http://www.apache.org> and in many commercialproducts). The particular server application is not fundamental, andothers may be used without limitation, on variants of POSIX-likeoperating systems, WINDOWS operating systems from Microsoft Corp. ofRedmond, Wash., or other operating systems.

[0022] Process flow initiates at a ‘start’ terminal 2010 and continuesto receive a ‘request’ data block 2020. In this illustrative embodiment,the ‘request’ data block 2020 is a Request Message in accordance withthe Hypertext Transfer Protocol (“HTTP”). However, as one of skill inthe art will appreciate, other embodiments of the invention could workwith other communication protocols and the particular protocol is notfundamental. In accordance with the draft HTTP/1.1 (available from WorldWide Web Consortium at <http://www.w3c.org> and the MIT Laboratory forComputer Science in Cambridge, Mass.), a Request Message comprises: aRequest Line and zero or more Message Headers. A compliant Request Linecomprises the URI and, in practice, typically several Message Headersare included in a Request Message that provide request modifyinginformation, for instance as set forth in the HTTP protocol.

[0023] Next, a ‘request URI extraction’ process 2030 extracts the URIfrom the Request Line and process flow continues to a ‘URI hashes todescriptor’ decision process 2040. Using a conventional case-insensitivehash function, the ‘URI hashes to descriptor’ decision process 2040hashes the URI received from the ‘request’ data block 2020 for a lookupoperation in the hash table 1100. (One of skill will appreciate that useof a hash table is not fundamental; other data models could be used;preferably, the data model provides O(1) speed for lookup independent ofthe size of data set.) If the URI is not found in the hash table 1100,the ‘URI hashes to descriptor’ decision process 2040 exits through its‘no’ branch and process flow continues to a ‘URI rewrite mapping’process 2050.

[0024] The ‘URI rewrite mapping’ process 2050 performs a translationfrom the URI to an internal name for the resource associated with theURI. Typically the internal name is a location in the filesystem of thehardware running the server process. However, the URI may also map to,for instance, debugging information, a directory listing, or one ofseveral default internal names of the server process. When Apache isused, the mod_rewrite uniform resource identifier rewriting engine maybe used, and analogously functioning modules may be used with otherservers, if desired. Typically, the flexible mapping from the URI to aninternal name involves relatively computationally expensive parsing andextraction. Appreciable efficiencies may be obtained by caching theresults of this mapping so that it need not be repeated for succeedingrequests for the same resource. When the internal name for the resourcehas been determined, process flow then continues to a ‘URI descriptorcreation’ process 2060.

[0025] The ‘URI descriptor creation’ process 2060 uses the URI and theinternal name to create a URI Descriptor data structure that will, inpart, cache the mapping performed by the ‘URI rewrite mapping’ process2050. The ‘URI descriptor creation’ process 2060 creates a copy of theURI Descriptor data structure in the hash table 1100, sets the firstvariable 1455 indicating the resource is cached, sets the secondvariable 1460 indicating the type of file, and the third variable 1465indicating the internal name for the resource.

[0026] Process flow continues to a ‘plainfile’ decision process 2070 anda ‘small’ decision process 2075 that determine whether the resource is acandidate for caching. In some variations of this illustrativeembodiments two criteria must be met for the resource to be cached.First, the resource must be a plain file, and second the file must be‘small.’ In variations, response headers can be cached even when theresource is not, for instance, if the resource is not ‘small’.

[0027] In some illustrative embodiments, a resource is a plain file ifit does not require running executable code to generate a response,although other criteria could also be used. If the ‘plainfile’ decisionprocess 2070 determines the resource is a plainfile, it exits throughits ‘yes’ branch and process flow continues to the ‘small’ decisionprocess 2075. Whether a file is ‘small’ for the purposes of thisillustrative embodiment is a function of the caching policy, the serverarchitecture, and the memory architecture of the hardware running theserver process. First, the caching policy determines the number of filesto cache. Some preferred embodiments use a FIFO cache with a fixed sizeof 20 files, although many other caching policies are within the levelof ordinary skill in the art and could be used as well. It will beappreciated, that the more complex the collection of resourcesfrequently requested from the server, the more desirable it becomes tohave a cache with a greater fixed size; analogously, the less complex,the smaller the fixed size may be set. Second, the server architecturedetermines the number caches that need to be stored. A typical serverrunning in a POSIX-like environment, e.g., Apache v.1.3.6 running underSOLARIS v. 2.7, will have several concurrently-executing requesthandling processes each with an independent address space. If eachrequest handling process stores its own cache in its own address space,then there are as many caches as there are request handling process.Another typical situation is where a server runs in a multithreadedenvironment. In this instance, several concurrently executing requesthandling processes can share a common address space. A single cache canbe stored in the common address space and accessed by all requesthandling processes (suitably synchronized). Third, the amount ofphysical memory available for cache(s) on the machine executing theserver process provides an upper bound. Considering these factors, asize for a ‘small’ file may be determined as follows:$f = {\frac{M}{N \cdot C}\quad \text{where}}$ $\begin{matrix}{f = \quad \text{Size~~of~~a~~'small'~~file}} \\{M = \quad \text{Memory~~available~~for~~cache(s)}} \\{N = \quad \text{The~~number~~independent~~caches}} \\{C = \quad \text{Number~~of~~files~~per~~cache}}\end{matrix}$

[0028] It will be apparent to one skilled in the art that other cachepolices will give rise to differing ways to make similar determinationsand for conventional cache policies, it is within the ordinary skill inthe art to suitably ascertain which files are desirable to cache.

[0029] If the ‘small’ decision process 2075 determines the resource is‘small’, it exits through its ‘yes’ branch and process flow continues toan ‘open file’ process 2080 that opens the file associated with theresource. Next a ‘read file into d.body’ process 2090 reads the fileassociated with the resource into the buffer referenced by the sixthvariable 1480, e.g, it creates the cached response body 1500, andassigns a value to the fourth variable 1470 of the length of the fileassociated with the resource. Process flow continues to a ‘d.headersbuilding’ process 2100 that constructs the response headers. Inembodiments that use the HTTP protocol, the response is a ResponseMessage in accordance with the HTTP protocol and the response headersgenerally provide information about the server and about further accessto the resource identified by the request. The ‘d.headers building’process 2100 also reads the constructed response headers into the bufferreferenced by the seventh variable 1485, e.g, the cached response header1600, and assigns a value to the fifth variable 1475 of the length ofthe response headers. This substantially completes generation of theresponse and storage of intermediate state information in the URIDescriptor data structure.

[0030] This done, the response can be transmitted to the client and a‘d.headers writing’ process 2110 begins communicating the response bywriting the response headers from the cached response header 1600referenced by the seventh variable 1485. In some instances, not allheaders for the response can be cached and must be created dynamicallyat the time of transmitting the response, for instance the current dateand time. A ‘dynamic headers writing’ process 2120 continuescommunicating the response to the client by writing any response headersthat need to be created at the time of generating the response.

[0031] Next, a ‘body cached’ decision process 2125 determines whetherthe body of the resource is cached. In some variations, response headersare cached while the body of the resource is not. This may occur, forinstance, when the resource is not a small file. In other instances, itmay be desirable only to cache response headers. The ‘body cached’decision process 2125 determines whether the body is cached. If so, the‘body cached’ decision process 2125 exits through its ‘yes’ branch and a‘d.body writing’ process 2130 completes communicating the response bywriting the response body from the cached response body 1500 referencedby the sixth variable 1480 in the URI Descriptor data structure. Processflow completes through an ‘end’ terminal 2140.

[0032] If the ‘body cached’ decision process 2125 determines the body isnot cached, it exits through its ‘no’ branch and process flow continuesan ‘open file’ process 2127 that opens the file associated with theresource for reading, a ‘read file’ process 2180 that reads theresource, and a ‘write file’ process 2190 that completes the response bywriting the resource. Process flow then completes through the ‘end’terminal 2140.

[0033] Returning to the ‘small’ decision process 2075, when the resourceis not ‘small’, the ‘small’ decision process 2075 exits through its ‘no’branch and the response is generated. Response generation begins with an‘open file’ process 2160 that opens the file associated with theresource for reading. Next, a ‘headers writing’ process 2170 generatesand writes the response headers and the ‘read file’ process 2180 readsthe resource. Then, the ‘write file’ process 2190 completes the responseby writing the resource. Process flow then completes through the ‘end’terminal 2140.

[0034] In varations where response headers are cached even when theresource itself is not, for instance when the resource is not ‘small’,the ‘headers writing’ process 2170 may also perform the function ofcaching the response headers. This may occur as was described above withreference to the ‘d.headers building’ process 2100.

[0035] Returning to the ‘plainfile’ decision process 2070, if itdetermines the resource is not a plain file, the ‘plainfile’ decisionprocess 2070 exits through its ‘no’ branch and process flow continues toa ‘run executable’ process 2200. The ‘run executable’ process 2200executes the instructions, e.g. servlet, script, database query, etc.,responsible for generating the response. The ‘run executable’ process2200 interacts with a ‘header parsing’ process 2210 that parses thoseheaders from the request received in the ‘request’ data block 2020 thatare necessary for generating the response. It will be appreciated thatthe request headers are only parsed when the ‘run executable’ process2200 is entered, and then only those headers are parsed that arerequired by the particular instructions responsible for generating theresponse. Eliminating unnecessary parsing of headers from the requestappreciably reduces the average computational overhead necessary forresponse generation. When the ‘run executable’ process 2200 completesgeneration of the response, it outputs the response for transmission tothe client and process flow completes through the ‘end’ terminal 2140.

[0036] Now returning to the ‘URI hashes to descriptor’ decision process2040, if the URI from the ‘request’ data block 2020 is found when alookup is performed in the hash table 1100, the ‘URI hashes todescriptor’ decision process 2040, exits through its ‘yes’ branch. Thisoccurs when a second (or later) request for a given resource occurs (andthe URI Descriptor data structure associated with the resource has notalready been displaced from the cache). Process flow continues to an‘d.cached’ decision process 2220. The ‘d.cached’ decision process 2220consults the first variable 1455 in the URI Descriptor data structure todetermine whether the resource associated with the request URI iscached. If the resource is cached, the ‘d.cached’ decision process 2220exits through its ‘yes’ branch to the ‘d.headers writing’ process 2110and the ‘dynamic headers writing’ process 2120 that write the cachedheaders, as well as any dynamically-created headers for the response.Next, the ‘body cached’ decision process 2125 determines whether thebody of the response is cached and process flow continues to the ‘openfile’ process 2127 or the ‘d.body writing’ process 2130, to generate thebody of the response, as previously described. Process flow thencompletes through the ‘end’ terminal 2140.

[0037] If the ‘d.cached’ decision process 2220, determines that theresource associated with the request URI is not cached, it exits throughits ‘no’ branch and process flow continues to a ‘plain file’ decisionprocess 2150. If the ‘plain file’ decision process 2150 determines theresource is not a plain file, it exits through its ‘no’ branch andprocess flow continues to the ‘run executable’ process 2200 andcontinues as was previously described. If the ‘plain file’ decisionprocess 2150 determines the response is a plain file, it exits throughits ‘yes’ branch and process flow continues to the ‘open file’ process2160 and the response is generated as was previously described.

[0038]FIG. 3 depicts a computer system 3000 capable of embodying aspectsof the invention. The computer system 3000 comprises a microprocessor3010, a memory 3020 and an input/output system 3030. The memory 3020 iscapable of being configured to provide a data structure 3040, such asthe cache data architecture 1000, which may contain data manipulated bythe computer system 3000 when embodying aspects of the invention.Further illustrated is a media drive 3070, such as a disk drive, CD-ROMdrive, or the like. The media drive 3070 may operate with acomputer-usable storage medium 3075 capable of storing computer-readableprogram code able to configure the computer system 3000 to embodyaspects of the invention. The input/output system 3030 may also operatewith a keyboard 3050, a display 3060, a data network 3080 such as theinternet or the like (through an appropriate network interface), a massdata storage 3085, and a pointing device 3090. As illustrated, thecomputer system 3000 is general-purpose computing machinery. As one ofskill recognizes, programmed instructions may configure general purposecomputing machinery to embody structures capable of performing functionsin accordance with aspects of the invention. Special purpose computingmachinery comprising, for example, an application specific integratedcircuit (ASIC) may also be used. One skilled in the art will recognize,numerous structures of programmed or programmable logic capable of beingconfigured to embody aspects of the invention. In some illustrativeembodiments, the computer system 3000 is an UltraSPARC workstation fromSun Microsystems of Mountain View, Calif., that runs the SOLARISoperating system (also from Sun) and the Apache HTTP (web) serverapplication.

[0039] All documents, standards, protocols, and draft protocols referredto herein are incorporated herein by this reference in their entirety.

[0040] The present invention has been described in terms of featuresillustrative embodiments. To fully described the features of the presentinvention, embodiments were selected that fully illustrated the featuresof the invention. However, one skilled in the art will understand thatvarious modifications, alterations, and elimination of elements may bemade without departing from the scope of the invention. Accordingly, thescope of the invention is not to be limited to the particularembodiments discussed herein, but should be defined only by the allowedclaims and equivalents thereof.

What is claimed is:
 1. A computer-implemented method for efficientlygenerating responses for repeated resource requests, said methodcomprising: receiving a first request for a first resource; derivingintermediate state information used in generating a first response tosaid first request; caching said intermediate state information;receiving a second request for said first resource; retrieving saidintermediate state information; and generating a second response to saidsecond request using said intermediate state information.
 2. The methodaccording to claim 1 wherein said intermediate state informationcomprises: an internal name corresponding to said first resource; and atype of said first resource.
 3. The method according to claim 1 whereinsaid intermediate state information comprises said first resource. 4.The method according to claim 1 wherein said intermediate stateinformation comprises a plurality of response header lines for saidfirst resource.
 5. Apparatus comprising a processor, a memory, a networkinterface, and a file system, programmed instructions configuring saidapparatus to accept connections in order to service requests by sendingresponses thereto, said apparatus further configured with programmedinstructions comprising: a request receiver configured for receiving afirst request for a first resource; a request handler configured forderiving intermediate state information used in generating a firstresponse to said first request; a cache storing said intermediate stateinformation; and a request handler configured for retrieving saidintermediate state information and further configured for generating asecond response to said second request using said intermediate stateinformation
 6. An apparatus according to claim 5 wherein saidintermediate state information comprises: an internal name correspondingto said first resource; and a type of said first resource.
 7. Anapparatus according to claim 5 wherein said intermediate stateinformation comprises said first resource.
 8. A computer-implementedmethod for efficiently generating responses for repeated resourcerequests comprising: receiving a first request for a first resource,said first request comprising a resource identifier and requestmodifying information; determining whether generating a response forsaid first request requires parsing said request modifying information;and, if not, generating said response without parsing said requestmodifying information.
 9. Apparatus comprising a processor, a memory, anetwork interface, and a file system, programmed instructionsconfiguring said apparatus to accept connections in order to servicerequests by sending responses thereto, said apparatus further configuredwith programmed instructions comprising: a request receiver configuredfor receiving a first request for a first resource, said first requestcomprising a resource identifier and request modifying information; aresponse generator configured for generating a response to said firstrequest and further configured for determining whether generating saidresponse requires parsing said request modifying information; and arequest modifying information parser configured to parse requestmodifying information only when said response generator determinesgenerating said response requires parsing said request modifyinginformation.
 10. A computer program product comprising acomputer-readable medium having computer readable instructions encodedthereon for efficiently generating responses for repeated resourcerequests, comprising; computer program instructions configured to causea computer to receive a first request and a second request for a firstresource; computer program instructions configured to cause a computerto generate a first response to said first request using intermediatestate information derived in generating said first response; computerprogram instructions configured to cause a computer to cache saidintermediate state information; computer program instructions configuredto cause a computer to retrieve said intermediate state information; andcomputer program instructions configured to cause a computer to generatea second response to said second request using said intermediate stateinformation.
 11. The computer program product according to claim 10wherein said intermediate state information comprises: an internal namecorresponding to said first resource; and a type of said first resource.12. The computer program product according to claim 10 wherein saidintermediate state information comprises said first resource.
 13. Thecomputer program product according to claim 10 wherein said intermediatestate information comprises a plurality of response header lines forsaid first resource.
 14. A computer program product comprising acomputer-readable medium having computer readable instructions encodedthereon for reducing parsing of request modifying information,comprising; computer program instructions configured to cause a computerto receive a first request for a first resource, said first requestcomprising a resource identifier and request modifying information;computer program instructions configured to cause a computer todetermine whether s generating a response for said first requestrequires parsing said request modifying information; and computerprogram instructions configured to cause a computer to generate saidresponse without parsing said request modifying information ifgenerating said response does not require parsing said request modifyinginformation.